Automating with SharePoint list events

Automating lists

If you’ve been working with SharePoint lists you’ve inevitably run into the need to know when an item/document has been created or edited, or something else.

There’s multiple ways to achieve this, in this post I’ll go over some of the options that can enable us to do this, weigh the pros and cons of each, so you can take the best possible decision for your project!

List rules

Rules are perhaps the newest take on automating lists, they’re easy for an end user to setup, all it takes is going to the list you want to automate and clicking through a quick wizard

List rules are super great because they allow you to really quickly setup a rule, and have a super intuitive UI, however they’re greatly limited in terms of what they can do, it’s pretty much limited to when x changes (and y == z) send and email to <user> so use cases could include stuff like a task list where the assignee might change and need an email - another downside is that there’s no way to change the email that’s being sent from, and up until recently it was just sent from a random Microsoft account, now recently Microsoft announced that they would change this so that the user who last changed the rule will be the sender, this is not necessarily great either, as you’re now suddenly sending emails without knowing it. - an option to customize the email would be really nice, maybe that’s coming in the future.

Power Automate (Logic apps)

The next easiest way to get going is with Power Automate, Microsoft’s low code automation tool, when you go to create a instant cloud flow you’ll have a bunch of options, and more are coming often!

Now with Power Automate your options are essentially unlimited, with like 900+ of connectors the limit really is your imagination, from sending emails to posting to twitter, anything is possible.

Honestly this is most likely the best option to what you’re trying to do, with two major exceptions:

Provisioned sites - one of the things that’re really frustrating with the SharePoint triggers is that they’re all based on a single list, I haven’t found an efficient way to use flows distributed, some people achieve this with a column formatter, this is an alright solution, but it requires the user to press a button, so I’m not really counting it here.

The other is the trigger delay, if you’re running a “free” tier flow, it seems to be delayed by 1-5 minutes, this goes down to seconds if you’re on premium, so if speed is important to you, you really need to be on premium. Now this is not too much of an issue, but more something to be aware of in case you’re going back and doing something to the list item, you might run into a situation where the item has already changed again! - so please go for premium if speed is important.

Websockets

The first pro-code option we’ll look at is websockets, websockets are super awesome because they provide an very much instant notification when a change happens, this can client side be done with the @microsoft/sp-list-subscription, but should also be possible from daemon code, unfortunately with a websocket the only notification you get is “something changed” - not anything in regards to which item, this means you can hook it up to a list and display the lists data somewhere else and you’ll know immediately if something in the lists changes, unfortunately you’ll just have to load the lists data to see what.

I see this mainly useful for dashboards since we don’t know which item changed, I’ve only used this once in production and that was a summary web part that displayed some real time stats based on a SharePoint list, unfortunately I ended up switching up this model due to a bug that now appears to be resolved, but I don’t see this a great option due simply to the fact that you don’t know what changed, also server to server websocket connections are fragile in my experience.

Webhooks

Webhooks are probably the solution Microsoft really wants you to use! - they provide a wide range of events from the list - ranging from new attachments to item moved, this is great because unlike with the websocket you actually know what happened, but at the same time the webhook does not contain compromising data as you’ll only get a reference to what site, list and item that have changed, so it’s up to you to find the new and old values for instance.

Creating a webhook is a bit more cumbersome than most of the other methods discussed here, but once you’ve done it a few times it’s easy enough, there are however more than a few disadvantages to webhooks, some of which I think Microsoft really needs to address at some point.

My main problems are best summed up here:

• They’re pretty slow to fire, like 1-5 minutes, timing seems random
• They work as a subscription - which means you’ll need to “renew” them at least every 180 days, if you’re running a provisioning scenario where you might have 1000+ sites with lists you need to be subscribed to this quickly becomes an overhead
• You have to respond with an OK http message within 5 seconds, essentially rendering any non always-on hosting option useless
• If your backend fails too many times in a given period the webhook will be removed

Now this does not mean you shouldn’t use webhooks, they’re still great, and definitely the way you should move, also to be somewhat future proof, especially compared the next option we’ll look at that does all of the above, (and IMO does it better), the main reason I end up not using webhooks is simply the set up and maintenance that comes with them.

But that’s not to say that webhooks don’t have their advantages, one of those being that it’s (AFAIK) the only one of the tools listed here that have a built in retry logic, meaning that if your backend code is unavailable SharePoint will retry in order to ensure that you get the notification - this is really a game changer compared to the other options!

Another huge benefit is the security aspect, with a webhook you get the bare minimum amount of data to know what has changed, compared to the next option we’ll look at this is way more secure!

Remote event receivers (ReR)

Perhaps the oldest option on this list (I did skip Workflows since I pretty much only work with SPO) is ReRs, they’re still my most used option for a few reasons, which frustrates me because they’re very much a legacy technology, they require an ACS app registration to setup (or a user, but please never do that, it’ll be tied to that account and die with the account) - ReRs have some advantages compared to the above options, perhaps my favorite is the synchronous option, this means we have the option to intercept the create/edit event, and even more powerfully we have an option to block them!

This means you can setup joined unique values, in cases where you want there to only be one item with a given set of values, or you want to make sure people actually filled out a field with more than just a “.” - another usage is syncing real time to another service.

Another really cool thing about ReRs is how fast even the async operations are triggered, we’re talking less then 2 seconds from item created till you receive your SOAP request … you read that right, now luckily there are plenty of good XML to C# tools online, or even built right into Visual Studio so you can easily parse the request and use it in anything you want - I mostly go for Azure Functions.

Now unlike the above options with ReRs you actually get to know more info then just “something changed”, or “this item changed” - we get a full list of the changed properties (slightly different behavior in libraries and lists, see The ReR properties table at the bottom of this page) this means you can track how the users have changed data, even without looking in the version history, but also that there’s data from your list potentially going to third parties if you don’t know where your ReR is pointing to!

Another great thing about ReRs are that they’re dead simple in their implementation, simply provide a URL, and you’re off to the races, no need to validate the URL, or anything, and no required response, it’s just off to the races, this also means they’re VERY MUCH fire and forget, and if your backend is down you WILL loose requests, so proceed with caution!.

TL;DR

• List rules are great for informing users something changed
• Power Automate is the perfect low code option to know when things change
• Websockets are best used when you would normally pull the data every few seconds
• Webhooks are the way to go if you’re developing a solution today!
• Remote event receivers are the legacy tech that really needs a modernizations (please Microsoft)

Remote event receivers properties table

Full credit to this page for building the lists, I’ve seen them around the web for years, but my bookmark had died when I was writing this post, so here’s another backup